Security-JAWS 第28回レポート #secjaws #secjaws28 #jawsug #サイバーセキュリティは全員参加
Security-JAWS 第28回のレポートです。re:CapもありSecurity LakeやControl Towerもあり、いろんな話がありました。AWSベストプラクティスのアンケート調査結果レポートもあります！
こんにちは、臼田です。
Security JAWS 第28回が開催されましたのでレポート致します。
Security-JAWS【第28回】 勉強会 2023年02月28日(火) - Security-JAWS | Doorkeeper
動画
レポート
この本読もう(宣伝)
re:Inforceのジャパンツアーやるってよ！
Session1: 2023年サイバーセキュリティ月間について 内閣官房 内閣サイバーセキュリティセンター（NISC）基本戦略第1グループ 参事官補佐 浦川 隆志さん
- サイバーセキュリティ月間なのでハッシュタグをつけてつぶやこう！
- サイバーセキュリティ月間は法律で決められたものだって知ってた？
- サイバーセキュリティ基本法で決められている
- サイバーセキュリティ意識・行動強化プログラムも改定した
- 資料はこのあたりにある
- 課題: 実際に手を動かしてやってくれるところと共同でやらないといけない
- 普及啓発主体という
- シニア・非就業層向け、こども・家庭向け、中小企業・組織向けの取り組みなどが書いてある
- 国は普及啓発主体が活用できる仕組み・枠組みを作る役割
- そのうちの1つがサイバーセキュリティ月間
- サイバーセキュリティ月間
- 2/1〜3/18の期間で開催
- サイバーセキュリティ対策9か条
- もともとあったが内容を見直して改定した
- 信頼できる相談窓口の周知
- 都道府県警「サイバー犯罪相談窓口」などを周知している
- インターネットの安全・安心ハンドブック Ver.5.00
- いわゆる黄色本
- 1月末に改定した
- 今上がっている完全版以外にも、抜粋版を公開予定
- 経営層向け意識啓発動画コンテンツ
- 結構気合を入れて作った
- NISC含めていろんな政府機関がこういったコンテンツを使っていく
- みんなが活用していくものなので、使って欲しい
- #サイバーセキュリティは全員参加
感想
コンテンツがいっぱいあっていいですね！ぜひ展開をしていきましょう！ #サイバーセキュリティは全員参加
Session2: AWS re:Invent 2022 Security re:Cap Head of Security Sales, Worldwide Specialist Organization, Amazon Web Services Japan G.K. 桐山 隼人さん
- re:InventのアップデートやKeynote/リーダーシップセッションなどの内容を扱っていく
- Keynoteから
- 経済が不確実だからこそのクラウド
- 世界の紛争などもあり通常よりもよりサイバーのリスクが上がっている
- インフレやサプライチェーンの混乱、半導体不足などもある
- 費用対効果の高いクラウドでコスト削減を実現したお客様が沢山いる
- Do More with Less
- 今まで以上により多くのことを、少ないリソースでやらないといけない
- セキュリティを考える人達はこれを特に考えていかないといけない
- どうやるか
- いくつの(数)
- 多層防御をしていく
- 一部だけでは意味がない
- どれくらい(量)
- 従量課金で利用できる
- コストならAWS Budgetsで可視化したり
- どれくらい(質)
- ベストプラクティスを活用できているか
- 例えばTrusted Advisorを利用して可視化する
- いくつの(数)
- より少ないリソースでどうするか
- Open Cybersecurity Schema Frameworkを共同設立
- 元来セキュリティベンダー製品は独自の互換性のないフォーマットでログを生成していた
- フォーマットを合わせて今まで以上のことをやる
- セキュリティチームがそのログを集めて分析するためにAmazon Security Lakeをプレビューで提供
- Open Cybersecurity Schema Frameworkを共同設立
- 経済が不確実だからこそのクラウド
- AWSセキュリティ新サービス
- Amazon Security Lake
- クラウド、オンプレミス、カスタムソースからのデータをリージョン全体で一元化
- 複数の分析ツールと簡単に共有できる
- セキュリティデータの管理と所有権を維持しながら利用できる
- パートナーもすでにいっぱい
- Amazon Verified Permissions
- 認証をビジネスロジックから切り離すことでアプリケーション開発を加速する
- 許可を与えるのはRBACとABACの組み合わせ
- Policy-based access control(PBAC)
- Cedarという言語で記述できる
- 一元化されたポリシー管理ができる
- ランタイム認可
- アプリケーションがVerified Permissionsに許可を与えていいか確認する
- キャッシュをきかせることも可能
- きめ細やかな権限の監査
- CloudTrailで監査証跡を取得できる
- Amazon Security Lake
- 既存サービスのアップデート
- AWS Wickr
- GAとなった
- メッセージ、ビデオ通話、ファイル共有などコラボレーションができる
- データの暗号化などの要件が厳しい場合に検討できるサービス
- Amazon GuardDuty RDS Protection
- プレビュー
- Auroraのログインイベントを分析できるようになった
- Amazon Inspector for Lambda functions
- EC2/コンテナに加えてLambdaもチェックできる
- Amazon Macie Automated Sensitive Data Discovery
- 自動的にサンプリング分析できる
- コストを抑えて検知ができる
- AWS KMS External Key Store(XKS)
- AWS KMSのルートキーの格納先としてAWS外にある鍵管理システムを選択可能に
- オンプレミスのHSMを利用できる
- AWS Config Proactive Compliance
- 今まではリソースをプロビジョニングした後Configルールのチェックをしていた
- 今回のでプロビジョニング前のテンプレートに対してチェックできるようになった
- CI/CDに組み込んだりできる
- シフトレフトできる
- AWS Wickr
- re:Cap資料と動画もあがってます
- 少ないリソースで新しい仕組みを使って対応していきましょう
感想
今回のre:Inventもいっぱい来ましたね！新しいサービスや機能も、まだまだプレビューのものも多いですが、使っていきましょう！
Session3: Security LakeとSplunk Victoria Experienceの連携をやってみた ういちさん
- 基幹システムとか情報システムとか工場のスマート化とかやっている
- やっていることはデータドリブンにやっていく
- いろんなAWS外も含めたサービスを組み合わせて使っている
- Cloud WANを使っている
- 組織でAWSの利用を開始sたのは2013年のSAPを移行したところから
- 何をしてきたか
- 出てきたわからない単語を調べてやって…
- ログ基盤の構成
- Splunkもいるけど構成要素がいろいろある
- ログの入れ方もいろいろある
- きれいに入れるのが難しい
- 説明もしんどい
- 説明するのがわかりにくいということはメンテナンス負荷もある
- どこからの取り込みがうまくいっていないかとか
- 結構同じログを送ってしまう
- Splunkは従量課金
- 引き継ぐためにも整理したい
- Splunk Cloud Victoria Experienceがでた
- IDMがいらなくなった
- 新しい構成案を考えた
- ポイント
- 極力わかりやすくする
- operationログと前後を整備し、エスカレーションルールもシンプルに構成する
- PagerDuty含めてきれいに
- Security Lakeを含めて構成を考えた
- Security HubからSecurity Lakeとか
- Security Hubが直接取り込めるのはConfig / Detective / GuardDuty / Inspector
- これらをSecurity HubのFindingsとしてSecurity Lakeに入れる
- これ以外にもCloudTrail / VPC Flow Logs / Route53ログなども個別にSecurity Lakeへ
- DataDogからPagerDutyの線などもある
- Security HubからSecurity Lakeとか
- ポイント
- やってみた
- Splunk Cloud Victoria Experienceへの移行はSplunkに依頼するだけ
- 想定内
- 設定をいくつかユーザーが移行する必要がある
- 想定外
- アラートがいくつか消えた
- 項目を確認して追加対応した
- Security Lake
- AWSのブログを見てポチポチやっていった
- Splunkとの連携はAdd-onを使う
- S3のイベントトリガーからSQSを経由してSplunkがそれを拾う
- 感想
- 初期設定はかなり楽
- 一個一個のログをポチポチ取り込む必要が無くなった
- けど確認が終わっていない
- もう少し時間をかけて検証が必要
- 初期設定はかなり楽
- こんなのが出てた
- Data Manager for Splunk Cloud
- これを使うほうが楽かを確認したい
- Data Manager for Splunk Cloud
- Splunk Cloudへのログ取り込みのベストプラクティスはまだ出てない
感想
セキュリティの様々なログをSecurity Lakeで一元管理できるのは、お話頂いたように分かりづらいので、簡素化してわかりやすくできるのは強みですね。プレビューですのでそこは注意しましょう。
Session4: Cloudセキュリティの実態 - 2022 State of Public Cloud Security Report概略 Orca Security APAC シニアセールスエンジニア 山口 央さん
- 目的
- クラウドセキュリティの実態を共有して恒常的な意識喚起のきっかけを作る
- 判明した実態
- 基礎的なセキュリティ対策が欠如していることが判明
- 36%の組織が機密情報を暗号化していない
- 33%の組織がRootアカウントをMFA無しで運用
- 70%の組織はKubernetes APIをパブリックに公開
- 他にも色々
- 多くの組織がセキュリティの悩みがあるととれる
- 推奨
- 日々の資産把握と脆弱性対策がリスク軽減の最短距離
- 新しい機能への追随も大事だけど、基本的なことをちゃんとやろう
- MFAはMust
- などなど
- 新しい機能への追随も大事だけど、基本的なことをちゃんとやろう
- 分業が大前提
- DataやApplicationに対する対策は常にお客様依存
- クラウドがどのようなモデルでも最終的にはお客様
- 日々の資産把握と脆弱性対策がリスク軽減の最短距離
- 具体的な対策
- 最新に保持
- 攻撃の大半は既知の脆弱性が的
- 10%の組織は10年以上前に発見された脆弱性を放置
- Workload上の脆弱性のうち1年以内に発見された脆弱性は50程度
- 新たに発見されたものよりわかっている脆弱性への対応をまずやろう
- 78%の攻撃の第1ステップは既知の攻撃から
- 攻撃の大半は既知の脆弱性が的
- 設定ミスは避けられない
- データ漏洩は99%ユーザーによる設定ミスから発生すると予想
- いろんなペルソナのユーザーがいるので避けられない
- 99%の組織がデフォルトのAWS管理のKMSを利用
- 70%の組織が作成から90日以上経過したAccess Keyを保持
- 77%の組織がDefault Portが設定されたRDSを運用
- データ漏洩は99%ユーザーによる設定ミスから発生すると予想
- IAMのリスクを予防
- 継続的かつ一貫性のある予防で発生しうるCloudのRiskは大幅に軽減できる
- 半数のAWS環境は最低1つのクロスアカウントが存在する
- 最新に保持
- デモ
- いろんなクラウドの情報をダッシュボードで一元管理
- 最新のCVEに該当するAssetの情報を一発で見れる
- インスタンスが停止していても情報収集できている
- 検索画面でいろいろできる
- MFAの無いユーザーをクエリする
- そのユーザーにフォーカスすると、他にも関連する問題を確認できる
- チケットシステムに連携できる
- RDSも検索
- グラフ表示でもみれる
- クレジットカード情報が暗号化されずに入っている
- 検知だけではなく対応復旧できる
- 最近ではChatGTPを使って対応方法を生成できる
- MFAの無いユーザーをクエリする
- まとめ
- 完全なリスク回避は不可能
- 日々の資産把握と脆弱性対策が最短距離
- AWSネイティブ+αが現実的
感想
設定ミスは避けられないのはそのとおりですね！基本的なところだからこそ、ちゃんと対策していきたいですね。
Session5: マニュアルを書かねばならなくなったので、ついでにAWS Control Towerの入門書を書いてみました。 kinnekoさん
- 自己紹介
- 基本はネットワークと組み込みLinux屋
- 160万台規模のIoTシステムを作ったり
- IT業界を歩いていると突然クマに遭遇することがある
- 「ちょっとアカウントも増えてきたので証跡保管なんとかしてくれ」と上司に言われた
- 「Control Towerを入れるとできるらしい」と言われた
- 運用とか大きく変わってしまうし説明とかに資料いるわな
- NRIの人も大変と言っていた
- 資料作ったらすごいボリュームになった
- 薄くない本を作っている
- Control Towerのアップデートはたくさん来る
- AWS SSOもAWS IAM Identity Centerに変わった
- Security Hubと統合した
- ガードレールっていう文字が消えた
- 包括的な制御管理機能(どういうこと？)
- 執筆は終わったけどどんどん手を入れている
- 発展途上のAWSサービスについての本を書くのは無謀
- 薄くない本の姉妹編として準備の薄い本も頒布している
- ここから本編
- AWS Control Towerとは
- 最初は証跡保管とガードレールによるセキュリティ保護がメインだったようだ
- 最近はアカウントの統合管理押し
- 機能
- 複数のAWSアカウントの統合管理
- いろんなサービスが使われているので事前知識が必要
- 理解するためには地図がいる
- なんでこんな面倒な機能を利用するのか
- AWSアカウントをそのまま使う
- 人が増えてVPCを分けたり、Lambdaの同時実行数を気にしたり
- 経費管理区分がしにくい、タグを付ける
- CI/CDやったり
- 自動化したり
- IAM増えたり
- AWSアカウントを増やしたり
- どのアカウントにどの情報でログインするか
- 辞める人がいるとか
- 1サービス1AWSアカウントがいい
- Control Towerを入れると全部楽になる…というわけではない
- 入れないよりはだいぶんマシ！
- AWSアカウントの削除が気軽にできる
- ユーザーの管理が楽になる
- 使えるリージョンを強制できる
- 大阪リージョンの対応はまだですか？
- 証跡管理できる
- 困ること
- 新しく作ったAWSアカウントではEC2を一定時間起動した実績がないとAWS Control Towerが失敗する
- 用語が不統一
- Auditアカウントの使い方がよくわからない
- ガードレールどれ使ったらいいかわからん
- rootの警告が消せない
- いろいろあるけど使ったほうがいい
感想
困るところもまだまだ色々ありますが、AWS Control Towerも継続的に機能追加などされていますので、これも含めたAWS Organizationsによる全体管理はやっていくといいですね。
Session6: 「AWSセキュリティのベストプラクティスに関する利用実態調査」のレポート完成報告 Security-JAWS
- あのアンケートのレポートが完成しました！
- 「AWSセキュリティのベストプラクティスに関する利用実態調査」のレポートです
- 130ページの大ボリューム
- 20の分析結果とSecurity-JAWSの提言を載せています
- 推しポイント
- 継続的なリスク評価を行っていますか？
- AWS環境を操作するためにどのような方法でアクセスしますか？
- 重要と定義されたデータをどのように客観的に評価・識別していますか？
- AWS環境の重要度が高いデータを破棄する時に行っていることを教えてください
- 今後の展開
- 3/10にイベント登壇
- グローバルにもアンケートをとります
- レポートはこちら
Session7: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー
Q. セキュリティにかける費用対効果を示したり、具体的なインシデント事例が知りたいです。
- 「AWS S3 Data breach」で調べたりする
- 何に対する対策かにもよる
- 発生するリスクと発生確率で計算したりもできる
- しかしセキュリティは買えば終わるものではない
- 物事に原理的に含まれているセキュリティもある
- 設計時にかけるコストがセキュリティだけのものでもない
- 難しい
Q. 何が出来れば「セキュリティエンジニア」を名乗れると思いますか？ （定義したいというよりは、色々な考え方があると思うので、皆さんのご意見を伺いたいです）
- 全員セキュリティエンジニアでいいのでは
- セキュリティ + エンジニア
- いろんなエンジニアリングがある
- 工学を使って課題を解決する人
- こんなRoleの分類もある
Q. AWSを使ってAPI提供サービスの基盤構築をしています。 主要構成：Cognito(認証)、API Gateway、Lambda、DynamoDB セキュリティ面をAWS Well-Architeced Severless Applications Lensの「Security pillar」やOWASP API TOP10を参考に確認しているのですが、正直どこまで対応するか決めかねています。 ガチガチにセキュリティを固めている記事を読んだことはありますが、クレカや重要個人情報を扱っているわけではないので、いい塩梅を探しております。 AWS WAFはどういうケースで合った方が良いか、CloudWatchでどこまでログを取ればよいのかなど、答えて頂けるとありがたいです。
- 原理的なセキュリティは先にやったほうがいい、WAFは少し後でもいい
- 守るべきものの資産の洗い出しは先にやるべき
- ログはCloudWatch Logsは何でも入れると高いので、アプリ側とも合わせたログレベルの設計に合わせるといい
- 特にLambdaのログは出そうと思えば沢山出せるので流量を調節する
- こっちも参考になる
Session8: Security-JAWS 2022年度振り返り、2023年度の目標 Security-JAWS運営メンバー
- アウトプットしないのは知的な便秘
- おかげさまでSecurity-JAWS3,700名を超える登録
- ここしばらくの対応
- 2022/02; Security-JAWS#24
- 2022/05: Security-JAWS#25
- 2022/05: IPAのレポートのインタビュー回答
- 2022/08: Security-JAWS#26
- 2022/11: Security-JAWS#27
- 2023/02: Security-JAWS with Toaru AWS SA#1
- 2023/02: Security-JAWS#28
- 2023/02: Security-JAWS Insightsレポート
- 2023/03: AWS Security and Risk Management Forum登壇
- 2023年のスケジュール
- 2023/05 Security-JAWS#29
- そして、8月は30回！
- ハイブリッドでできたらいいな
- 今後のアナウンスも要チェック
- これからもSecurity-JAWSはコミュニティとしていろいろやっていきたい
- どんどん色んな人にアウトプットしてもらいたい
- Community is so important
さいごに
いっぱいアウトプットがありましたね。アンケート結果のレポートぜひ見て拡散してください！
